Many of today's operating systems provide multi-threaded capability. With this capability, an operating system is able to support concurrent execution of multiple sets of code, multiple concurrent executions of the same set of code, or both.
In a computer having a single processor, the practical effect of multi-threading is that the multiple threads share the processor. Since the processor can execute only one thread at a time, the processor will execute one thread to a certain execution point or for a certain period of time. The processor then performs a context switch and begins executing another thread. The processor will execute that thread until a certain execution point is reached or until a time limit has been reached. The processor then performs another context switch and begins executing another thread. This other thread may be the previous thread, or it may be another thread. By switching from thread to thread in this manner, the processor services each thread and provides the impression that the multiple threads are being executed concurrently.
In a computer having multiple processors, the execution of the various threads can be truly concurrent. For example, if a computer has five processors and there are currently five threads executing in the computer, then each processor can be executing one of the threads. Since each processor has the processing resources to execute its own thread, the multiple threads can be truly executed concurrently and in parallel. Many of today's high power computers are multi-processor computers. These multi-processor computers provide the processing power needed to execute some of today's more resource-intensive programs.
One of the drawbacks of multi-processor computers is that they are not as scalable as would be desired. Multi-processor computers can accommodate only a finite number of processors, typically in the 16-32 processor range, which may not be enough for heavy computation. For this and other reasons, there has been a movement in recent times away from large multi-processor computers towards a grid-based computing model.
In a computing grid, a plurality of individual resource computers are coupled together via one or more networks. Each of these resource computers may be a single processor computer or a multi-processor computer. Access to the processing resources of the resource computers is controlled by a distributed resource manager (DRM). When a client computer has a job to be run, it submits the job to the DRM. In response, the DRM selects one (or more) of the resource computers, and assigns the job to that resource computer to be run thereon. After the job is completed, the DRM receives the results of the job from the resource computer and passes the results back to the client computer. In this manner, the DRM acts as the access point to the grid, and utilizes the resources in the computing grid to execute jobs. During a busy time, a client computer may submit multiple jobs to the DRM, which in turn, may assign those jobs to various resource computers for execution thereon. During a slow time, a client computer may submit very few or even no jobs to the DRM. As shown by this discussion, a computing grid provides a client computer with great computing flexibility and scalability. No longer does the client computer have to provide all of its own computing resources. Rather, it can call upon the computing resources of the grid as needed.
While grid computing provides many advantageous, its adoption by large enterprises has been relatively slow. There have been several reasons for this slow adoption. One reason has been the lack of a standard interface for invoking the functionalities of the DRM. Different DRM makers have implemented different proprietary interfaces. Because of this, application developers have not been able to develop applications that are compatible with all DRM's. Instead, they have been forced to tailor their applications for specific DRM's. This has slowed the development of applications that are grid-aware/grid-compatible. To rectify this situation, an organization known as the Global Grid Forum has created a standard interface known as DRMAA (distributed resource management application API) for invoking the functionalities of a DRM. If all DRM makers start conforming to this standard, then it will be possible for application developers to write applications that are compatible with all DRM's.
Another reason for the slow adoption of grid computing has been the fact that grid computing represents a significant change in computing paradigm. The current prevailing computing paradigm (the one used in single and multi-processor computers) is thread-oriented. Under this paradigm, when an application wishes to have a set of code executed concurrently with itself, it makes a call to the operating system to create another thread and to use that thread to concurrently execute the set of code. Because all threads created by an operating system are assumed to run in the same computer in the same process space, the application can make liberal use of logical constructs, such as pointers, that are valid only within a process space of a particular computer. The same cannot be done in a grid computing environment. In a grid, it is not known beforehand which resource computer will be selected by the DRM to execute a job. Thus, computer and/or process space specific assumptions cannot be made. As a result, the thread-oriented paradigm cannot be used across a grid.
Instead, in grid-based computing, a job-oriented paradigm is used. With the job-oriented paradigm, each request to execute a set of code is packaged as a job in such a way that it is more self-contained. By doing so, it is possible for the DRM to assign the job to any resource computer for execution thereon. The packaging of a request is just one of the differences between the thread-oriented paradigm and the job-oriented paradigm. There are many other significant differences. Because of these differences, it is not possible for an application written in accordance with the thread-oriented paradigm to operate in a job-oriented paradigm unless significant changes are made to the application. Because such extensive changes would require a significant investment in resources, very few existing applications have been altered to make them job-oriented, and hence, grid-aware/grid-compatible.
Yet another reason for the slow adoption of grid computing has been that most application developers are accustomed to programming in the thread-oriented paradigm. To write grid-aware applications, developers would have to change from their current paradigm to the job-oriented paradigm. This requires significant investment on the part of the developers, and is difficult to do. Because of this, relatively few grid-aware/grid-compatible applications have been developed.